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Abstract 

The general building contractor is presented with an 
information model as an approach for deriving a high- 
level work plan of construction activities applied to road 
building. Road construction activities are represented in 
a Road Plan Model (RPM), which is modelled in the 
ISO standard STEP/ EXPRESS and adopts various con- 
cepts from the GARM notation. The integration with the 
preceding road design stage and the succeeding phase of 
resource scheduling is discussed within the framework 
of a Road Construction Model. Construction knowledge 
is applied to the road design and the terrain model of the 
surrounding road infrastructure for the instantiation of 
the RPM. Issues regarding the implementation of a road 
planner application supporting the RPM are discussed. 


during the various phases of a project life cycle. Sharing 
and maintaining these project data among multiple dis- 
ciplines and throughout a project life cycle is a complex 
and difficult task. The project data needs to be stored, 
retrieved, manipulated and updated by many partici- 
pants, each with his own view of the information. This 
leads to a step-by-step integration strategy, in which the 
several stages are carefully rationalized, automated and 
subsequently inserted in the global system. For a 
description of the multi-agent architecture proposed for 
the site controller, see This architecture is based on 
an object-oriented concept for modelling the product 
information as well as the processes, and is intended to 
link CAD systems, relational database, knowledge- 
based systems and other conventional application soft- 
ware. 


Introduction 

The work presented in this paper is being done 
within the ESPRIT m project 6660 - RoadRobot - Oper- 
ator Assisted Mobile Road Robot for Heavy Duty Civil 
Engineering Applications. The project is partially 
funded by the European Commission under the ESPRIT 
R&D programme and involves seven partners in five 
european countries, ranging from research and technol- 
ogy organizations, a manufacturing company as end 
producer and a building contractor as end user. 

The objectives of this project are to adapt a generic 
control architecture to the requirements of the building 
iiidustry and to build up and integrate components 
needed for automated out-door construction purposes. 
The operation of the developed subsystems and control 
strategies will be demonstrated under real conditions by 
the integration of two autonomous prototypes of the 
road building application: a road paving machine and an 
excavator. 

The research institute Uninova is responsible for the 
development of the central site controller, which will 
integrate the working cells into a CIM environment, 
including functions of planning, scheduling, cost calcu- 
lation, production and manufacturing supervision. Large 
amounts of information are generated and consumed 


The STEP standard 

One of the problems of all CIM systems concerns 
the representation of the information to be accessed by 
the different agents of the (road) construction process. 
This implies the definition of common models for 
shared concepts in order to support an effective 
exchange of information. As the project favours the 
ideas of international standardisation works, we have 
considered the use of the ISO 10303 standard, the so- 
called STEP (STandard for the Exchange of Product 
model data) [51 , to model the information inside the CIM 
system. 

The STEP standard includes a formal information 
modelling language, called EXPRESS ^ used to spec- 
ify the objects belonging to a universe of discourse, the 
information units pertaining to those objects and the 
constraints on those objects. All tools inside our site 
controller will model the information according to this 
formalism and be able to access instances of EXPRESS 
entities. This implies the development of STEP transla- 
tors from supplier-specific file formats into EXPRESS 
entities which are then stored in the site controller’s 
common information system. 

The physical implementation of the information 
structure in a database will be based on a CIM architec- 
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ture similar to the one presented in the ESPRIT II 
project IMPPACT (Integrated Manufacturing of Prod- 
ucts and Processes using Advanced Computer Technol- 
ogies) ® - Chapter 2.4), and which was partially 
implemented by our research group within the European 
BRITE/ EURAM project CIMTOFI [1 °1. 

The GARM notation 

The General AEC Reference Model developed 
by W. Gielingh, describes the product model through so- 
called Product Definition Units (PDU). GARM is part of 
the draft proposal of the ISO standard STEP. The current 
version of the GARM concentrates on the requirement 
and design stages of the product life cycle. 

Basically, PDUs describe the objects (or parts of an 
object) that have to be handled. A PDU appears in dif- 
ferent stages during its life cycle: required stage, design 
stage, planning stage, production stage, etc. Only the 
first two life cycle stages are worked out. A PDU in the 
‘as-required’ stage is called Functional Unit (FU). A 
PDU in the ‘as-designed’ stage is called Technical Solu- 
tion (TS). These two stages are used for decomposition 
during the design of a PDU. 

GARM is based on the FU-TS decomposition. This 
construct expresses the fact that a top-down design 
process is ruled by the divide-to-conquer principle. 
Searching a TS for a set of requirements collected in a 
FU is done by breaking the TS up into lower order FUs, 
i.e. by dividing the problem into a number of smaller 
design problems. 

This principle can be visualized by means of a so- 
called Hamburger diagram (Fig. 1). Such a diagram rep- 
resents the product model as a hierarchical tree whose 
nodes consist of two semi-circles. The upper side sym- 
bolizes a FU and the lower side the selected TS. Decom- 
position levels may coincide with responsibilities, 
disciplines, contractor/ subcontractor/ manufacturer 
relationships, etc. 



Fig. 1: Hamburger diagram: decomposition tree 


Besides these vertical relations, which structure the 
FUs and TSs into a hierarchical tree, the various compo- 
nents at a FU-level may be related to each other (hori- 
zontal relations). GARM relates the FUs mutually by 
means of a network. These relations are called inter- 
faces. 

In the next chapter, we present a model that 
describes all the properties of a family of roads during 
the design process. Such a model is called a product 
type model . During the design process, a product model 
for a specific road is generated by choosing those prop- 
erties from the product type model that are needed to 
fulfil the specific requirements of that road. 

The Road Model Kernel 

During the analysis of the state-of-the-art in integra- 
tion of new technologies into building industry, it was 
evident that most established developments concentrate 
on computer-aided drafting. Here, several CAD pack- 
ages from different software suppliers have been identi- 
fied. Nevertheless, it also became obvious that one big 
problem associated to the rapid increase of specific 
CAD-software programs is the ability to exchange 
information between each other, not to mention with 
programs with other purposes during the life cycle of a 
product. 

The Dutch Ministry of Transport, Public Works and 
Water Management, in conjunction with TNO Building 
and Construction Research, has seen the need to lay a 
new foundation of a new standard for road development. 
This has led to the development of the so-called “Road 
Model Kernel” a product description of the road in 
the design stage based on the ISO/STEP standard. A 
STEP translator was developed which allows the 
exchange of the MOSS file format with the RMK with- 
out loss of information. 

The RMK was developed using GARM’s methods, 
and therefore describes the road in terms of FUs and 
TSs. However, the PDUs of the RMK are not real-world 
objects (or parts of objects) which can be obtained inde- 
pendently through construction processes and jointly 
form the ‘as-built’ road. Instead, they have been defined 
to reflect the viewpoint of the road designer as he con- 
quers the complex problem of designing a road. 

In several internal models used by road modelling 
packages, one often encounters two layers of decompo- 
sition: firstly a longitudinal decomposition and secondly 
a transversal decomposition. This longitudinal decom- 
position is often split into a longitudinal decomposition 
to describe the horizontal alignment and a longitudinal 
decomposition to describe the vertical alignment. 









The principle to decompose alternately and on hier- 
archically different levels into longitudinal and transver- 
sal seems to fit properly with the experience of the road 
designer, and was adopted by the RMK. 

Road-axes and road-nodes constitute the framework 
to describe the structure of the roads and their connec- 
tivity: the topology. However, this description does not 
incorporate sufficient information to extract the accurate 
shape of the road. This is done by adding the geometry 
to the road-axis as a separate entity. 

The FU road-geometry shapes one or more road- 
axes which will assemble a continuous chain. The road- 
geometry will make demands on the progression of cur- 
vature, horizontal as well as vertical. Alignment is the 
TS which can be selected for the FU road-geometry. 
Alignment decomposes into two interconnected net- 
works (chains) which describe separately the horizontal 
and vertical alignment. 

For the geometrical representation of the road, a spe- 
cific type of coordinate system must be chosen for the 


RMK. Because of its simplicity and flexibility, the RMK 
uses a floating around the z-axis rotating s-t-z coordi- 
nate system, which is related to the horizontal alignment 
curve. 

The s-axis maps one-to-one on this curve (longitudi- 
nal direction) and is embedded in the x-y plane. The t- 
axis is orthogonal (perpendicular) to the s-axis (trans- 
versal direction) and is also embedded in the x-y plane. 
The z-axis is equivalent to the z-axis of the fixed x-y-z 
coordinate system. 



Fig. 3: Coordinate system s-t-z vs x-y-z 



The horizontal and vertical alignment description in 
the RMK defines the curvature functions along the lon- 
gitudinal (s-axis) direction of the road. 

The alignment incorporates a chain of arcs intercon- 
nected by tangent nodes. Arcs may specify no curvature 
(straight), one (circular curve) or two curvatures to 
denote start and end magnitude (linear transition). 

The horizontal and vertical alignments are defined at 
a high level, dragging all lower level entities to follow 
automatically this primary shape. However, the influ- 
ence of a crossfall is dedicated to a specific transversal 
function. Therefore, a geometry entity should be 
imposed only to that specific transversal function (car- 
riageway geometry, slope geometry, ...). The TS cross- 
fall decomposes subsequently into a collection of 
tangent nodes containing the magnitude of a specific 
gradient. 

The Road Construction Model 

As presented by J. Everett in his paper construc- 
tion and manufacturing exhibit fundamental differences 
in where the interface or transition occurs between prod- 
uct design and process design or fabrication. In repeti- 
tive manufacturing operations, the product-process 
design team controls product and processes all the way 
down. However, in construction, there is little overlap 
between product design and process design or fabrica- 
tion. Architect/ engineers control product design but do 
not get involved in the building process other than to 
inspect the finished work for conformance to design 
specifications. Constructors control the fabrication proc- 
ess design but generally have little or no input into prod- 
uct design. A distinct separation exists between the 
product designers and or architect/ engineers, and the 
process designers or craft workers. In construction, the 
product designers and process designers are almost 
always separate organizations with different objectives. 

This is specially true for heavy-duty civil engineer- 
ing applications, like road construction, where the gap 
between the lower limit of design detail and the upper 
limit of machine technology is substantial, as very few 
practical examples of construction robotics or highly 
automated machines have been developed. 

As seen above, the Road Model Kernel represents 
the road design without any detail about the processes 
used to build the road. Until the product design and 
process design can be integrated by closing the gap 
between design and machine technology, we propose to 
use a step-by-step integration strategy which reflects the 
current way of work. 

During contacts with the entity responsible for the 


construction of highways in Portugal, Brisa, the follow- 
ing agents were identified and a description of their 

roles in the construction process is given below: 

• Based on the user’s needs, the construction owner 
Brisa defines the requirements of the road to be built 
and delivers these to the design team. 

• As the national authority for the design of high- 
ways, Brisa distributes the design regulations to the 
design team, which include for instance minimum 
values for the radius of curves depending on the 
requested speed, ways of calculating the earth vol- 
umes, norms about the composition and thickness of 
the paving layers depending on the soil resistance, 
etc. 

• The design team returns to the construction owner a 
set of documents (descriptive memory) as result of 
several design activities, such as (a) geometric draw- 
ings, (b) earthworks based on geological/ geotechni- 
cal studies, and (c) paving layer composition of the 
road sections. 

• As the national authority for the construction of 
highways, Brisa distributes general technical norms 
to the general contractor about the construction of 
highways, for instance about the material to use in 
earth-filling, classification of the soil based on spe- 
cific attributes and their application, the notion that 
the vertical alignment as defined in the design draw- 
ings refers to the surface course of the road or to the 
compacted base platform as well as transversally to 
the line limiting the carriageway and the left verge, 
the proceedings for the quality control of the earth- 
works and the paving, etc. 

• The general contractor hired receives the design 
documents from the construction owner as well as a 
contract specification book. The contract document 
specifies additional construction requirements to the 
general technical norms. Based on these, the general 
contractor plans how the road is to be built in order 
to maintain the requested deadlines and costs, requi- 
sitions the resources and carries out the site produc- 
tion, eventually by hiring sub-contractors. 

• Sub-contractors perform tasks and produce the 
products or components for the construction, for 
instance a sub-contractor is hired to build the bridge, 
another is hired to do all earthworks, etc. 

• Machinery lending firms provide equipment to the 
site. 

• Suppliers/ distributors supply and distribute mate- 
rial for the site facility, such as the asphalt plant sup- 
plies the asphalt mixture for the road paver, and gas 


stations supply petrol for the machinery, etc. 

As the RoadRobot project embarks all phases of 
road building from design to production, the RMK will 
be used as the ‘as-designed’ model of the road. For later 
processes like planning and production, and for the 
modelling of resources and activities, new modelling 
constructs have to be found and added to the previously 
presented GARM model. The Road Construction Model 
will be based on B. Luiten and F. Tolman’s “Building 
Product Model (BPM)” and will be used in our work 
for the integration of design and construction knowl- 
edge and information. 

For the Road Construction Model, the following 
stages have been identified (see Fig. 4): 

• the design stage, where the product road is described 
by the road designer in terms of its geometric 
requirements -> Road Model Kernel, 

• the planning stage, where the activities are identified 
by the general contractor as constant road sections to 
which they apply -> Road Plan Model, 

• the scheduling stage, where to each activity identi- 
fied at the previous stage the resources to realize 
them are assigned by the general contractor, in order 
to optimize time and costs -> Road Schedule Model, 


modelled in respectively a Product Definition Unit 
(PDU), an Activity Definition Unit (ADU) and a 
Resource Definition Unit (RDU). GARM has worked 
out concepts for PDU which are also suitable for ADU 
and RDU. To reuse modelling constructs and to avoid 
redundancy, common properties for PDU, ADU and 
RDU are modelled in a new entity called Construction 
Definition Unit (CDU). 

The relations between Product (PDU), Activities 
(ADU) and Resources (RDU) can be graphically mod- 
elled in NIAM (Fig. 5). 



• the construction stage, where the tasks are effec- 
tively issued to the working cells and their execution 
monitored, resulting in a built road which will be 
inspected relatively to its requirements. 

In a building project, three main groups of entities 
can be modelled: the Product, the Activities and the 
Resources. The information about these entities can be 



Fig. 4: The Road Construction Mode 


Fig. 5: NIAM diagram of the Building Product 


Examples of PDUs are: the product itself, parts of 
the product or features. For ADUs one can think of all 
the processes during the project: management, design, 
planning, and production processes. RDUs are resources 
used by ADUs, like manpower, equipment and raw 
materials. 

For a PDU the main characteristics are ‘shape’ and 
‘material’. Other characteristics can be derived from the 
main characteristics. For an ADU the main characteris- 
tics are ‘time constraints’, e.g. ‘must be performed 
before or after’, ‘can be performed independently of. 
For a RDU all characteristics have something to do with 
‘money’, e.g. ‘application costs’, ‘acquisition costs’, 
‘remainder value’. When the ADUs are related to 
RDUs, absolute time can be derived, e.g. ‘starting time, 
‘ending time* and ‘duration*. 

Examples of states are ‘as designed’, ‘as planned’ 
and ‘as built*. In general, an ADU is preceded by a PDU 
state and succeeded by a new PDU state. An ADU 
always uses one or more RDUs. It is possible that this 
ADU also changes the state of the RDU. 

As an example of the use of the Road Construction 
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Model, the paving activity of a three course carriageway 
section is partially worked out. The pavement consists 
of three asphalt courses which are sequentially applied 
over the preceding course. 

In Fig. 6, this activity is modelled in a NIAM dia- 
gram using the concepts of the Road Construction 
Model. At the three bottom levels of the diagram, the 
PDU decomposition is the one followed by the road 
designer as identified in the Road Model Kernel of Fig. 
2. The fourth level models the PDUs identified by the 
general contractor when planning the paving process of 
the designed carriageway, as will be shown in the Road 
Plan Model at Fig. 7, taking into account only the 
restrictions imposed by the surrounding road infrastruc- 
ture. The fifth level models the PDU decomposition fol- 
lowed for scheduling the planned paving process (Road 
Schedule Model), considering the time constraints and 
the resources available at the building site. Each of the 
Activities ‘design’, ‘plan’, ‘schedule’ and ‘apply’ mod- 
els the transition of one Model to the succeeding Model 
of the Road Construction Model, changing the state of 
the PDU from ‘as required’ to ‘as designed’, to ‘as 
planned’, to ‘as scheduled’ and finally to ‘as built’, 
respectively. 

The Road Plan Model 

In the present work, a “Road Plan Model” will be 
proposed, which describes the road in the ‘as-planned’ 
stage. In the same way as the RMK, the RPM represents 
the viewpoint of the general contractor when he takes 
the complete contract document delivered by the con- 
struction owner and creates the high-level work plan of 
construction activities. 

The purpose at the planning stage is to identify the 
road sections which require different types of construc- 
tion activities, and their dependencies. Each of these 
activities can be visualized as being executed by a work- 
ing cell composed of a set of resources which work 
jointly to realize that activity. These working cells are 
logical entities which will be instantiated during the 
scheduling stage with the necessary quantity of 
resources (machines and humans) in order to maintain 
deadlines and budgets. 

During contacts with several building contractors, 
the following high-level construction activities were 
identified, which are presented graphically in the 
GARM tree of Fig. 7. This tree forms the basis of the so- 
called “Road Plan Model”. 

A problem which was encountered in this stage of 
development, was the selection of proper names for all 
entities and objects essential to construct the data model. 


To provide some pattern to it, the next schema was used: 
The FU of the RPM identifies the activity to execute 
over a specific road section. The TS specifies the work- 
ing cell which satisfies that requirement. 

For example, suppose a specific road section passes 
over a valley or a river. The FU describes this road sec- 
tion with bridge construction activity ; indicating that the 
TS to obtain such a road section is the construction of a 
bridge by a bridge construction cell. 

Another example relates to the land clearing activity , 
which is satisfied by the clearing cell. The selection of 
the equipment composing this particular working cell 
depends on the diameter of the vegetation and on the 
size of the area. However, these questions are answered 
only at the scheduling stage, as the selection of equip- 
ment is also affected by whether there are alternate uses 
for equipment as well as by time limits. 

During the development of this model, a decision 
had to be taken concerning the depth of the RPM 
decomposition tree, i.e. the granularity of the working 
cells. As our purpose is to model the way of thinking of 
the general contractor while building the high-level 
work plan, the result is the one shown in Fig. 7. How- 
ever, the adopted GARM concept, which separates FUs 
and TSs, allows for more details to be added at the end 
(leaves) of the model. Specifically, this is done when 
planning and scheduling the resources inside a working 
cell. 

The granularity of the lower-order activities in the 
RPM (level of the leaves) defines the functionality of 
the working cells which can realize them and which will 
be allocated in the scheduling stage. In turn, each of the 
working cells must be able to plan and monitor the exe- 
cution of each of its resources (machines and humans). 
The higher the functionality of the working cells is, the 
more complex is the management of their resources. 
Here, the same approach to the just described CIM sys- 
tem can be applied. 

The vertical decomposition identifies road sections 
where the named activity is applicable and their decom- 
position into sub-sections for lower-order activities. The 
identification of each road section depends on the activ- 
ity to perform over it, which in turn depends on the con- 
nection of the road design to the surrounding road 
infrastructure. Usually, the general contractor defines a 
road section by indicating the initial and final station, 
i.e. the s-ordinate in the s-t-z coordinate system of the 
road design. 

The horizontal network structure describes the 
sequences and dependencies of the construction of each 
of the road sections, and therefore of the activities which 



realize them ( precedes , succeeds). 

Over the same road section, the activities have a 
well-defined precedence. For instance, earthmoving is 
performed before drainage, and drainage is done before 
paving, the surface course is put on top of the binder 
course, the art works (bridges, tunnels) are done in par- 
allel with the earthworks prior to paving. 

Between different road sections, it is also possible to 
define precedency. For instance, paving a road section is 
an activity which is further decomposed into lower- 
order activities: apply base course, then binder course 
and finally surface course. However, the successive 
application of each of the courses does not have to be 
made over the total length of the road section. That is, 
the road section to be paved may be decomposed into 
sub-sections, which allow a different, even simultaneous 
application of the layers; for instance apply the base 
course over the initial sub-section, then apply the binder 
course over that same sub-section, while applying the 
base course over the second sub-section, etc. 

This flexibility facilitates the scheduling of the activ- 
ities, allowing for the optimization of the temporal allo- 
cation of the working cells to each of the planned 
activities. For example, if two paving cells are available 


at the building site, their simultaneous use makes it pos- 
sible to optimize the execution time of the global activ- 
ity of paving a road section. Once activities are attached 
to product parts and resources to activities, production 
time and costs can be predicted. 

Implementation issues 

Within the RoadRobot project, this work will result 
in the implementation of a “Computer-Aided Planner”. 
Taking the instantiated RMK, the construction specifica- 
tions and some terrain model, this expert system will aid 
the general contractor in creating an instance of the 
RPM by specifying the road sections and the construc- 
tion activities which have to be realized over them. 

The proposed situation for the planning process is 




































Extract of the EXPRESS description of the Road Plan Model 

SCHEMA RoadPlanModel; 


ENTITY RoadPlan; 

plannedRoadAc tivi ty : 
END_ENT I T Y ; 

ENTITY ConstructionCell; 

artWorkActivi ty : LIST 

earthWorkActivity : LIST 
drainageActivit :y LIST 
pavingAc tivi ty : LIST 

supplWorkActivity : LIST 
END_ENTITY ; 


of ArtWorkActivity ; 
[1:?] of EarthWorkActivity; 
[1:?] of DrainageActivity; 
[1:?] of PavingAc tivi ty; 
[1:?] of SupplWorkActivity; 


ConstructionCell ; 
[ 1 :?] 


Paving 

ENTITY PavingAc tivi ty; 
requiredCell : 
precedes : 
section: 

END_ENT I T Y ; 

ENTITY PavingCell; 

baseActivity: LIST [1:?] of BaseCourseActivity; 

binderActivity: LIST [1:?] of BinderCourseActivity; 

surf aceAc tivi ty: LIST [1:?] of SurfaceCourseActivity; 

END_ENTITY; 

ENTITY BaseCourseActivity; 

requiredCell : BaseCoursePavingCell ; 

precedes : BinderCourseActivity; 

section: Section? 

qt: Ton; 

END_ ENTITY ; 


PavingCell ? 
SupplWorkAc t i vi ty ; 
Section; 


END_SCHEMA; 


described by the IDEFO diagram 191 on Fig. 8. 


RPM 


RMK instance 

terrain model 

construction 

specifications 



RPM Instance 


Fig. 8: IDEFO representation of the planning stage 


The translation of design information into process 
planning information is a translation process in which 
construction knowledge is applied to the design infor- 
mation. This knowledge can be classified into three cat- 
egories according to the scope of the statements: 


- general building knowledge 

knowledge applicable to every building product and 
project. 

- product type specific building knowledge 

knowledge applicable to specific product types, e.g. 
roads. 



- product specific building knowledge 

knowledge applicable to specific products of a cer- 
tain supplier, e.g. highways. 

- project specific building knowledge 

knowledge applicable to a specific building project.. 

The first category of knowledge refers to general 
construction knowledge. An example is the selection of 
the activity depending of the type of vegetation of the 
terrain at the building site. If there are trees, then there 
has to be an activity which cuts them off; if there is a 
building, then it must be demolished, be it for the con- 
struction of a road or of a building. 

The following two categories of knowledge are usu- 
ally available in regulations. For example, the width of 
the paving courses is determined by the type of soil 
under the road and the traffic which should be supported 
by the road. The first variable is given by the terrain 
model, the second one is specified in the requirements of 
the road design. 

The last category of knowledge is specific to a par- 
ticular construction project. The construction owner 
may specify that, during the earthworks, the soil of the 
platform is to be made constant, even when this means 
getting soil of the required resistance from a distant 
earth deposit, as it is impractical to vary the thickness of 
the asphalt courses during the paving process. Another 
example is the specification of the quality control points. 

Terrain model 

One problem of the RPM is the integration of the 
road design with the surrounding terrain model. Two 
viewpoints over the terrain are relevant: the geotechni- 
cal and the topographical. 

The geotechnical model describes the road corridor 
in terms of the geological characteristics of the under- 
ground soil: sand, rock, underground water rivers, etc. 
This model is important for the planning of construction 
activities and at the scheduling stage for the selection of 
resources to apply during a specific construction activ- 
ity: use a motorscraper for earthmoving sand, but an 
excavator for earthmoving clay. 

The topographical model describes the surface of the 
road corridor, including the identification and location 
of natural and human-made obstacles: vegetation, rivers, 
buildings, etc. This model allows the general contractor 
to plan the way to deal with each of the obstacles, 
namely which construction activity to use: demolish a 
building, cut off trees, build a bridge over a river, etc. 

Obviously, the functional modelling of the terrain in 
ISO/STEP is by itself an own project. Therefore, within 


the RoadRobot project, for the implementation of the 
site controller, an industry standard format will be 
selected for the digital terrain model (DTM), for 
instance the format TIN, which defines the surfaces by 
means of triangulated 3D facets. 

Conclusion 

This work suggests a Road Construction Model 
using concepts of GARM. For the decomposition of a 
PDU during its life-cycle, we chose to follow the con- 
struction process as much as possible, which resulted in 
the creation of several models, because such a decompo- 
sition supports all the aspect views without being far 
away from the mental world of the users in practice. 

The first model dedicated to the design process, the 
Road Model Kernel, was developed by the TNO- Build- 
ing and Construction Research institute and has already 
a working computer version. 

The present paper presents a conceptual model for 
the planning process of the road construction as prac- 
tised by the general contractor, the Road Plan Model. 

Further work 

To allow for the integration of design and construc- 
tion with the developed Road Construction Model, mod- 
els for activities and resources have to be worked out, 
similar to the product model, as well as the relations 
between these three entities. This includes detailing and 
implementing the Road Plan Model and the Road 
Schedule Model as was done with the Road Model Ker- 
nel. 
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